The present invention relates generally to accessing information in a database or databases and more particularly to techniques for providing answers to user queries using a database system.
Generally, no data updated timestamp is included as a data item of any table in a relational database. However, there is a technique that uses a timestamp of data registration/updating (hereinafter, to be referred to as data freshness) for each data item in case a plurality of data tables existing in a database or different databases are integrated into one table in a database system.
The technique is disclosed, for example, in JP-A-No. 10-312331, “Dynamic Access Method for Database,” by Kagei Koji, filed May 14, 1997, assigned to Hitachi, Ltd. When a data item is updated in one of several databases the database server of the effected database notifies a data freshness manager of the updated data name and the updating time immediately. The data freshness manager then updates the last update time of the corresponding data item in a data freshness table. Thus the data freshness manager maintains an internal table with the latest update time for the data item in each database in which the data item is stored. When a user queries for the data item, the data freshness manager uses the update time to select updated data item with the most recent time, from the one or more databases the item is stored in, to be returned to the user, i.e., the user gets the “freshest” data. The timestamps on the data item in the data freshness table are for internal use by the data freshness manager and are not accessible to the user. In business situations it is typically important to know when the data was last created/updated. For example, an accounting of the bills paid in the last month may be required. Thus there is a problem with the above data freshness technique hiding the timestamp from the user.
In addition, the data information used in actual business work does not always need the precise updated timestamp of data. The updated timestamp is decided by an application program that uses the subject database. For example, sales data in a business program may be totaled on the 20th of every month. Hence the exact date of the sale does not need to be displayed to the user, but may be “rounded-up” to the 20th. For example, sales on the 18th are included in the sales for the 20th. Or for example, the user may want to include data updated early in the morning of the 21st in the data of 20th sometimes. The above-described technique, however, does not have the flexibility for enabling such processing.
Furthermore, there may be times, when either a data freshness manager is not needed or has not been installed yet. Thus a timestamp, albeit an internal timestamp, may not be available. A data freshness manager may not be needed when the data item is unique to the databases. Thus the data item retrieved is normally the item stored in the unique location and there in no need for the overhead communication traffic of maintaining a separate freshness update table. Of course before the data freshness manager is installed, there is no freshness data table.
Thus there is a need for the user to have access to the timestamp of updated data and to be able to have such updated data processed to be used conveniently according to a company's business rules.